• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The invention relates to a method for creating a payment data structure, called the payment container. The invention also relates to the use of such a payment container by a processing server. the creation method is implemented by a mobile communication terminal, said payment container comprising at least one datum representative of a user's banking identifier, said method comprising: the selection (C20) by a user and via a human-machine interface, at least one attribute of said container; obtaining (C30), by the communication terminal, at least one datum representative of the user's bank card; - the validation (C40) by the user of the creation of the payment container; the transmission (C50) by said communication terminal of said payment container to a payment container processing server.
    公开号:FR3038429A1
    申请号:FR1556349
    申请日:2015-07-03
    公开日:2017-01-06
    发明作者:Pierre Quentin；Vincent Ducrohet；Michel Leger
    申请人:Ingenico Group SA；
    IPC主号:
    专利说明:

    Payment container, method of creation, method of treatment, devices and programs thereof. 1. Domain
    The present technique relates to the problem of payment. More particularly, the invention relates to the problem of payment by bank card. In Europe, the bank card is the most used means of payment. It is used both physically to make payments to merchants; It is also used to make payments online. However, she is also subject to fraud. 2. Prior Art
    A bank card makes it possible to make purchases according to two different types of processes: "card present" purchases are made when the user physically presents his bank card to a merchant, who has a physical payment terminal. In this configuration, depending on the countries, legislation and payment terminals available, the user (the buyer) can use either a smart card (also called a smartcard) or a magnetic stripe card (c). for example in the United States), or a contactless card. There are also multimodal maps that include the three previously mentioned technologies. "Card Not Present" (CNP) purchases are also possible using a credit card. These are mainly online purchases and also by phone that are made using a computer, tablet, smartphone or phone. To make this type of purchase, the user makes an entry, or communicates visual data of his card: card number, date of validity, name of the holder, visual cryptogram. This data is transmitted, via a communication network, to one or more servers, so that the payment can be made.
    The difference between these two types of payment is major. As much as it is easy to use a bank card in "present card" mode, it is tedious to have to enter his credit card data into forms of web pages. Thus, many people store their credit card data within a file to make payment transactions simpler. Solutions make it possible to manage this data in a centralized manner (for example DashLane ™). These software solutions, installed on the communication device (computer or tablet) of the user, can automatically enter, in the fields provided for this purpose, the data that was previously entered in the software.
    However, on the one hand, it makes it necessary to enter this data into third-party software, which must first be installed on the user's communication device; on the other hand, this solution requires to trust the publisher of this software for the conservation of these data. Online solutions also exist: they do not have to install software on user communication device, but they still need to trust a publisher (eg Google ™) for the retention of this data . This confidence has been greatly altered in recent years. Moreover, this solution for preserving credit card data within the communication device may be problematic in the event of theft or loss of the communication device.
    Another solution called "Card-on-File", allows storage of credit card data directly to the merchant. The merchant keeps, within its software infrastructure, the credit card data. This simplifies the payment process since once the user has logged in, it is just necessary to accept the payment or order for the payment to be effective. This solution, however, is not advantageous because it requires to have confidence in all online merchants likely to have the credit card data of the user (in this case, we must above all have confidence in the infrastructure of these traders, and trust that they are protected against theft and usurpation). This solution is also not definitive because when the card expires (for example when it comes to its expiry date), it is necessary to update all banking data on the websites or organization from which a "Card-on-File" solution has been implemented (eg credit, insurance, etc.). Finally, the main problem of the "Card-on-File" technique is ultimately to give his credit card data without insurance of their destination or end use. In general, credit card fraud is mainly carried out for online payments. However, the loss or theft of a bank card is an event that can have significant repercussions for those involved: withdrawal of cash (especially if the theft of the card was accompanied by the theft of the PIN accompanying the one here), online payments.
    To overcome 3. Summary
    The present technique does not have these disadvantages of the prior art. More particularly, the present technique relates to a transactional data processing method in a secure manner that provides a high level of usability for consumers. With this technique, payment can be made safely with a low level of fraud; In addition, the proposed solution is simple for the user and does not slow down the payment.
    More particularly, in a first aspect, there is disclosed a method for creating a payment data structure, called a payment container, a creation method implemented by a mobile communication terminal, said payment container comprising at least one data item. representative of a bank identifier of a user.
    According to the present technique, the method comprises: selecting, by a user and via a human-machine interface, at least one attribute of said container; obtaining, by the communication terminal, at least one datum representative of the user's bank card; validation by the user of the creation of the payment container; transmitting, by said communication terminal, said payment container to a payment container processing server.
    Thus, the user can define in a simple and secure way, a sum of money that he can subsequently use to make a payment, without the user needing to use his credit card.
    According to a particular embodiment, said step of obtaining by the payment terminal, minus a datum representative of the user's bank card, comprises: a step of transmission, to said bank card, via an interface non-contact data transmission, a request for obtaining data, in the form of a signal; a step of receiving a response to said request, in the form of a modulated signal; a step of decoding said modulated signal delivering said at least one datum.
    Thus, the user does not even need to enter the data of his bank card; It is enough for him to affix this one on his communication terminal.
    According to a particular embodiment, said step of obtaining by the payment terminal, minus a datum representative of the user's bank card, comprises: a step of activating a device for shooting the communication terminal; a step of obtaining, with the aid of the shooting device, an image of the bank card; a step of implementing a character recognition module, from the image of the bank card, delivering said at least one data.
    Thus, the user does not even need to enter the data of his bank card; It is enough for him to take this one in photo using his communication terminal.
    According to a particular characteristic, the method further comprises a step of determining, by said communication terminal, a value representative of a transmission attribute of said payment container.
    According to one particular characteristic, the method furthermore comprises, when the value representative of the transmission attribute of said payment container is positive, a step of determining, by said communication terminal, a value representative of a debit attribute. of said payment container.
    According to a particular characteristic, the creation method characterized in that it comprises, prior to the selection of a container parameter, the activation, on the communication terminal of the user, of a container management module. payment ; the selection within this module of a so-called container creation mode of operation.
    According to a particular characteristic, the activation of the management module is accompanied by the authentication of said user to which said communication terminal and said payment card belong.
    According to a particular embodiment, the selection, by a user and via a human-machine interface, of at least one attribute of said container comprises the selection of at least one attribute value for at least one the following parameters: date of validity of the payment container; period of validity of the payment container; amount of the payment container; category of beneficiary of the payment container; beneficiary of the payment container.
    In another embodiment, the technique also relates to a device for creating a payment data structure, called a payment container, said payment container comprising at least one datum representative of a bank identifier of a user.
    Such a device comprising at least one module configured to allow: the selection, by a user and via a human-machine interface, of at least one attribute of said container; obtaining, by the communication terminal, at least one datum representative of the user's bank card; validation by the user of the creation of the payment container; transmitting, by said communication terminal, said payment container to a payment container processing server.
    Such a module can be in a hardware or software forma. In a hardware form, such a module takes for example the form of a secure processor specially configured to implement the proposed technique.
    According to a second aspect, there is also disclosed a method of processing, by a processing server, a payment data structure, said payment container, said payment container being used with a payment server. merchant by a user having a communication terminal linked to said payment container, characterized in that it comprises the following steps: receiving data from the payment terminal, including the identifier of the payment container; obtaining a merchant identifier, possibly accompanied by a merchant category code when it is not provided by the merchant; according to the identifier of the payment container, determining an identifier of a banking establishment to which the payment container is attached; according to the bank identifier of the payment container, obtaining a payment authorization; and when the payment authorization issued, a step of transmitting, to the merchant terminal, data representative of the acceptance of the transaction.
    Thus, a payment can be implemented, using a payment container, without requiring the intervention of a credit card used to create this payment container.
    According to a particular embodiment, said step of obtaining a payment authorization comprises the following steps: when the banking establishment of the payment container is the same as the banking establishment of the processing server: obtaining the attributes of the container ; checking the remaining balance within the payment container; when the remaining balance within the payment container is greater than the transaction amount: verification that none of the attributes of the payment container are in contradiction with the transaction data; when none of the payment attributes are violated, issue of the payment authorization; subtracting a transaction amount from the remaining balance within the payment container; when the remaining balance within the payment container is less than the transaction amount, transmission of a no authorization;
    According to a particular embodiment, said step of obtaining a payment authorization comprises the following steps: when the banking establishment of the payment container is different from the banking establishment of the processing server: identification of the processing server to which the transaction data must be transmitted; transmitting the transaction data to this processing server; receipt of authorization or refusal of payment.
    The technique also relates to a processing server of a payment data structure, called a payment container, said payment container being used by a merchant by a user having a payment terminal. communication related to said payment container. Such a server comprises means for: receiving data from the payment terminal, including the identifier of the payment container; obtaining a merchant identifier, possibly accompanied by a merchant category code when it is not provided by the merchant; according to the identifier of the payment container, determining an identifier of a banking establishment to which the payment container is attached; according to the bank identifier of the payment container, obtaining a payment authorization; and when the payment authorization issued, a step of transmitting, to the merchant terminal, data representative of the acceptance of the transaction; Other aspects of the present technique are also disclosed herein. According to a preferred implementation, the various steps of the methods according to the proposed technique are implemented by one or more software or computer programs, comprising software instructions intended to be executed by a data processor of a relay module according to the technique. proposed and being designed to control the execution of the different process steps.
    Accordingly, the proposed technique is also directed to a program that can be executed by a computer or a data processor, which program includes instructions for controlling the execution of the steps of a method as mentioned above.
    This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
    The proposed technique is also aimed at a data carrier readable by a data processor, and including instructions of a program as mentioned above.
    The information carrier may be any entity or device capable of storing the program. For example, the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard. On the other hand, the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The program according to the proposed technique can be downloaded in particular on an Internet type network.
    Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
    According to one embodiment, the proposed technique is implemented by means of software and / or hardware components. In this context, the term "module" may correspond in this document as well to a software component, a hardware component or a set of hardware and software components.
    A software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software capable of implementing a function or a program. set of functions, as described below for the module concerned. Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, router, etc.) and is capable of accessing the hardware resources of this physical entity (memories, recording media, bus communication cards, input / output electronic cards, user interfaces, etc.).
    In the same way, a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions, as described below for the module concerned. It may be a hardware component that is programmable or has an integrated processor for executing software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing a firmware ( firmware), etc.
    Each component of the previously described system naturally implements its own software modules.
    The various embodiments mentioned above are combinable with each other for the implementation of the proposed technique. 4. Figures Other features and advantages of the proposed technique will appear more clearly on reading the following description of a preferred embodiment, given as a simple illustrative and non-limiting example, and the appended drawings, among which: Figure 1 shows a payment container according to the present technique; Figure 2 describes the steps implemented to create a payment container. Figure 3 the steps implemented, server side, to use a payment container. Figure 4 briefly describes the physical architecture of a device for creating and using a payment container. Figure 5 briefly describes the physical architecture of the processing server. 5. Description
    As stated above, the purpose of this is to simplify payment transactions in particular situations. The technique aims to answer a problem of payment or transfer of money. The proposed technique is particularly applicable to the use (payment, transfer) of a certain amount of money without having to use his bank card. The technique is based in particular on the implementation of a payment container, which includes a certain amount of information to make a payment in a simple and fast manner. The described technique also relates to the payment processing performed with the payment container. These processes are mainly performed with a transaction processing server, also called a processing server. Such a processing server may, depending on the embodiments and operational conditions, be a bank server (i.e. a server of a banking institution). It can also be an intermediary server (for example a hub that organizes and processes all the transactions of a group of merchants and / or merchants, or it can be an intermediary server. , which is the link between banking servers belonging to different banking institutions 5.1.
    The payment container is a data structure, which can optionally be encrypted (and thus secure) and contains a certain amount of information relating to a sum of money. The payment container can be defined as an envelope containing a certain amount of money associated with a bank card of a specific bank account (in this case, the bank account of the user who creates the payment container). Figure 1 illustrates a payment container (PC).
    Depending on the implementations and operational implementations, this sum of money (MNY) comes with a number of attributes: attributes are "public" (AttrPub) and others are private (AttrPriv) . Possible public attributes include at least one temporal data (TPS), which can be a duration of use or a use-by date, a maximum amount (MAX), a beneficiary (BEN) and / or a category of beneficiary (CBEN), the location of use (LOCU). Other data, for security and regulatory purposes, are private (AttrPriv): such as the date (DAT) to which the container is created, the place (approximate or not) (LOCC) of this creation, can be included. Private attributes help to ensure non-repudiation of the payment container. They also help to guard against fraud. A certain number of private attributes are inserted by the processing server itself, during the validation by the terminal. These private attributes are not editable by users.
    Each attribute of the payment container has a specific function: the validity date determines a deadline for using the payment container; beyond this date, the container is no longer usable; the deadline is substantially equal, in terms of function to the time limit: once past the time limit, the container is no longer usable; the maximum amount does not determine the amount of the container. The maximum amount determines the maximum sum of money for which the container can be used each time; for example, a container may contain a sum of € 100 and the maximum amount may be € 20. Therefore, a transaction using this container will be limited to a maximum amount of € 20; the beneficiary category determines the type of merchant with whom the container can be used. For example, the user may choose to limit the use of the container to "food" type businesses, excluding tobacco sales businesses; this aspect is explained in detail below; the recipient determines a particular trader with whom the container can be used; this aspect is explained in detail below; the usage location defines a geographical sphere within which the container can be used (city, region, country, etc.);
    With regard to the beneficiary, or category of beneficiary, it is offered the possibility to the user, to determine the type of purchase allowed with the container. The user thus has the possibility of restricting the use of the container. Thus, even if an ill-intentioned individual would be able to obtain the user's communication terminal and would succeed in launching a payment transaction with a container, the verification of the beneficiary or the beneficiary category of the container makes it possible to ensure that the ill-intentioned individual will not be able to use the container as he wishes. This blocking of the payment container is made possible by comparing the MCC (merchant category code) defined for this merchant with a list of MCC authorized by the creator of the payment container.
    As for the beneficiary, the principle is the same as before: instead of selecting one or more MCCs, the user selects one or more merchant IDs with which he wishes the container is usable.
    Once the payment container is created (see below), it is transmitted to the processing server for registration. It is considered that a processing server has sufficient security measures for the payment container to be stored in the server in decrypted form. However, it is also possible that the payment container is not transmitted to a processing server but directly to another communication terminal of another user. In this case, it is transmitted in an encrypted form.
    A payment container may also include an overflow attribute, the use of which may be limited (for example not for transmission and not for immediate debit): the override attribute is used to define an override percentage allowed, the amount of the container, for the maximum amount allowed. Such an attribute makes it possible to set a maximum amount range without being too strict on the amount itself.
    It should be noted that the payment container according to the present technique is not a wallet, such as for example the Google ™ or Paypal ™ portfolios. Indeed, these portfolios do not include the attributes that are defined for a payment container. In particular, they do not have an amount allocated, nor a duration of use or a category of beneficiary. These portfolios simply link an account number or a credit card number, a user within a banking institution, and a mobile communication terminal.
    It is also noted that the payment container is not a pre-authorization of debit. Indeed, the processing server, which keeps the payment container, does not immediately debit the user's account when creating or receiving this container. It also does not make a reservation of money: this means that there is no subtraction on the authorization amount of the customer's credit card (as is the case, for example, for establishment of a deposit by credit card). If the container is not used (for example because the container usage time is exceeded before any use) then no debit is made to the customer's account and no subtraction is made on the overall amount of authorization of the card. In a pre-authorization, on the contrary, although no amount of money is debited at the time of the pre-authorization, a subtraction is made from the payment limit of the bank card. Such subtraction is not without causing many problems to cardholders because it can lead to the blocking of the card even though no payment is actually made. In addition, a payment authorization can only be made (by a real payment) by the merchant who has made this pre-authorization, and not by any merchant, unlike the payment container.
    In a specific embodiment, the payment container can be debited immediately from the user's bank account. Such a situation may occur when the payment container is transmitted to a third party for use by a person who is not the creator of the payment container. When the user performs the creation of a payment container for a third party, the creator can value a specific attribute, called transmission attribute, indicating that the container is not intended for him. The third party to whom the attribute is intended is not necessarily known at the time of creation of the payment container. When the transmission attribute is set to "true", this opens the possibility of valuing a sub attribute (a dependent attribute) called the debit attribute. The debit attribute is used to indicate either that the payment container is to be debited immediately (attribute valued at "true"), or that the payment container should not be subject to a debit. immediate debit (attribute valued at "false").
    When an immediate debit is required, the amount of the payment container is debited from the user's bank account, by the implementation of an "EMV" type credit card transaction. For the user creator of the payment container, it is a conventional credit card transaction.
    When no immediate debit is required, the account of the user is debited according to several parameters that are explained later. 5.2. Creating a payment container 5.2.1. Creating a container on a communication terminal
    It is recalled that one of the problems that the payment container tries to answer is to allow users of smart communication terminals (smartphone type) to have a permanent means of payment simple and secure that replaces the bank card . Many users are worried about losing or stealing their card. The payment container offers such a possibility. It is also necessary that the payment container meets a number of other requirements, particularly in terms of ease of creation. The present method is described in connection with FIG.
    The inventors thus had the idea of implementing a method based on the use of an intelligent communication terminal of the smartphone (TC) type, this terminal being equipped on the one hand with a contactless reading interface ( NFC) or equipped with a camera (CAM) and secondly a payment container creation module (MCPC). According to the embodiments, such a module can be a dedicated module, a wallet module or a banking module (the user's banking module, available on its communication terminal). An advantage of using a bank module is that such a module is generally well secured. Therefore, insofar as the payment container is intimately linked to the user's bank card and / or bank account, it seems simple (and legitimate) that the cardholder's bank module is, in a particular operation, used to create the payment containers.
    The creation of a payment container includes: activation, (CIO) on the communication terminal of the user of the module; selecting (C10-1) within this module a so-called container creation mode of operation; the selection and / or input (C20) by the user of the attributes of the container (date or duration of validity, amount of container, beneficiary and / or category of beneficiary); the valuation (if any) of the transmission attribute; by default, the transmission attribute takes the value "false", and in the case where this attribute is set to "true", the valuation of an identifier of a recipient; the valuation (if any) of the debit attribute; by default, the debit attribute is set to "false"; obtaining (C30) a credit card data item (for example, affixing the user's bank card to the communication terminal, alternatively to affixing the card (in the case of the NFC), communication terminal camera can be used to take a snapshot of the user's bank card and perform character recognition); the validation (C40) by the user of the creation of the payment container; this happens for example by pressing a validation button. the transmission (C50) of the payment container to a processing server (SRVT). 5.2.2. Processing, by the processing server, of the container created by the communication terminal
    Once created on the user's communication terminal, the payment container is transmitted, in a secure form, to the processing server. The processing server implements a processing method which comprises: receiving the payment container, comprising a decryption step, with one or more keys in the possession of the processing server; assigning an identifier for uniquely identifying the container; retransmitting this identifier to the communication terminal of the creator user; storing, in a suitable data structure, this container.
    The treatment of the container, including in particular, in case of positioning of the flow attribute to "true", a step of debiting the amount of the container.
    The payment container is then ready to be used, either by the communication terminal which has created it or by another channel. 5.2.3. Transmission, by the processing server, to a recipient, of the container created by the communication terminal.
    The processing of the payment container may also comprise a step of transmission of the payment container, by the processing server (for example the banking server), to a receiving entity (for example another processing server or a banking server). The step of transmitting the payment container occurs when the payment container is intended to be used by another person. The processing server is then in charge of searching for this other person. This is done using the "recipient" attribute, which includes an identifier of the user to whom the payment container is intended. This identifier can take several forms, two of which are specified below. The identifier is used by the processing server either directly to carry out a transmission of the payment container to the recipient (the simplest case corresponding to a known recipient of the processing server) or indirectly to obtain additional data making it possible to carry out a transmission. the payment container.
    In a first alternative, the identifier of the recipient is a bank identifier, known to the communication terminal that performs the creation of the payment container. This bank identifier may for example be the bank identifier corresponding to a recipient close to the user (a parent, a child, etc.). The bank identifier can be in the form of a simple account number (in which case the creator of the container and the recipient share the same bank). The bank identifier can also be a BIC or an IBAN (when the creator and the recipient do not share the same bank). Therefore, in this first alternative, the processing server performs either moving the container (ie the assignment of the container to another account) when the creator and recipient are managed by the same bank, or the transmission of the container. payment to a server of the recipient's bank.
    In a second alternative, the identifier is a piece of data representative of a contact of the user's communication terminal: the identifier is obtained after the selection, by the user, of a recipient in the contact list. From then on, the identifier can be a mobile phone number, an email address, an instant messaging identifier, etc. Therefore, in this second alternative, the processing server performs at least the following actions: creation of an information message; the message contains an address to which the recipient must connect (for example a URL); the address comprises a transmission identifier which is for example the result of a hash function whose parameters are the identifier of the recipient and an identifier of the payment container; transmission of the information message to the recipient using the identifier of the payment container (for example the message is an email when the identifier is an email address, the massage is an SMS or an MMS when the identifier is a mobile phone number, etc.); On receipt of this message, the recipient connects to the address it contains and performs the steps necessary for the transmission of the payment container. To ensure the security of the exchange, the steps involve security processes including dual identification processes and encryption processes. In a complementary manner, identification deletion processes can also be implemented. 5.2.4. Transmission by the communication terminal of the container created by the communication terminal to a recipient
    The processing of the payment container may also include a step of transmitting the payment container, by the communication terminal itself, to the communication terminal of the recipient user.
    To do this, when the user has validated a payment container including a transmission attribute set to "true", the selection of the recipient offers the possibility of selecting a so-called "local" transmission. The local transmission is to transfer locally, to a second communication terminal located nearby, the payment container. This second communication terminal is that of the recipient. The process is as follows: the communication terminal of the creator user is approached from the recipient's communication terminal; possibly, this step is preceded by the launch of the process by a validation button; the communication terminal of the creator user sends a request, for example an NFC or Bluetooth request, to the terminal of the destination user; the terminal of the recipient user responds to this request by transmitting a "recipient" identifier (it is for example an identifier of the bank module installed on the recipient's communication terminal, that the recipient user can for example take care of launch, or that will launch automatically); the "recipient" identifier is inserted in the payment container, in the "recipient" attribute; the payment container is encrypted and transmitted by NFC or Bluetooth to the recipient's terminal.
    This transmission is followed or preceded by a transmission to the processing server of the payment container so that the processing server can also process it. Incidentally, the payment container also includes data representative of the processing server, so that the communication terminal of the recipient can be able to locate the container. Indeed, this transmission to the recipient's terminal is completed by an exchange of data at the processing server or servers, as described above. 5.3. Using a payment container.
    Depending on the data it contains, the embodiments and the operational conditions, the payment container can then be used to make payments to merchants. It can also be used to make payments online. The use of a payment container at a merchant includes: activating a module on the user's communication terminal; it can be a banking module (ie the module of the bank from which the payment container is registered), or a wallet type module (of the English "wallet"); the selection, within this module, of a mode of operation called contactless payment; optionally, the selection of a payment container to be used (when multiple containers can be used); presentation of the communication terminal in front of the contactless reader of the merchant's payment terminal; during this presentation, the payment terminal detects the use of the payment container and implements, in connection with the processing server to which it is connected, a payment process which is explained below (processing process implemented). implemented by the server).
    Thus, the use of a payment container at a merchant is a simple operation, which does not require any particular effort on the part of the user. Indeed, instead of having to introduce his credit card, it is sufficient to affix his communication terminal on the payment terminal. Instead of entering a PIN, he just needs to enter a password in the payment container management module (for example the bank module). The use of a payment container for an online payment comprises: activating a module on the user's communication terminal; it can be a banking module (ie the module of the bank from which the payment container is registered), or a wallet type module (of the English "wallet"); the selection, within this module, of a mode of operation called online payment; optionally, the selection of a payment container to be used (when multiple containers can be used); generating, by the module, a payment data item; entering, within a given input area of the website (specific input area, linked to the type of payment by payment container), the payment data provided by the module; after this seizure, the merchant implements, in connection with the processing server to which it is connected, a payment process which is explained below.
    Thus, the use of an online payment container is a simple operation, which does not require more effort on the part of the user. Indeed, instead of entering credit card data, the user enters a data representative of a payment container.
    The benefits of using a payment container are numerous. Indeed, the user does not need to use his bank card; users are very cautious, so for example can leave their bank card in a safe place and be sure that it can not be lost or stolen. A typical use case of a payment container is that of a user who does not wish to bother with his credit card, for example during an afternoon at the beach, lest we he steals it and creates a container on his communication terminal. He created this container for a day, with an amount of 20 € for example. If the user then wants to make a purchase on the beach, for example a drink, he can then use his communication terminal to pay for this purchase. Another advantage is that in case of loss of the communication terminal, the maximum amount that can be used by a malicious person is limited to the amount of the container. Furthermore, it should be borne in mind that the smartphone-type communication terminals are geolocatable. Indeed, more and more manufacturers and service providers integrate directly into the smartphone technologies to find it if it were lost or stolen. This means that even in case of loss, the user is likely to find his phone.
    Another case of use of the payment container is that of a transfer of money between two users. When a user wishes to transmit a sum of money to another, he creates, on his communication terminal, a payment container of the sum he wishes to transmit. It values the transmission attribute to "true" and the flow attribute to "true" or "false" according to the will of the user. It validates the creation of the payment container.
    This is transmitted to the processing server which detects that the container must be transferred and must be immediately debited. The processing server then identifies the recipient (which can in this case be valued in the "recipient" attribute, for example by using a telephone number or another identifier, as was previously presented). Using this identifier, the processing server informs the recipient user that he benefits from a transfer of money via a payment container, and then implements the transmission method, by the processing server, to a recipient, the container created by the communication terminal. 5.4. Processing a payment container from a processing server.
    First of all, the case of the processing of a payment container by a processing server when a payment transaction is carried out using a payment container at a merchant. It is assumed, as a prerequisite, that the payment terminal is able to accept a payment via a container. As a general rule, this involves a software upgrade of the payment terminal (the vast majority of terminals have contactless payment modules, so a change of payment terminal is not necessary).
    At the time of payment, the user indicates to the merchant that he wishes to settle with a payment container. The merchant activates the terminal so that he can receive this type of payment then the user implements the method described above. When he presents the communication terminal in front of the payment terminal, the communication terminal transmits, to the payment terminal, the identifier of the payment container. The data exchanges between the payment terminal and the communication terminal are for example made using the ISO / IEC 14443-4: 2008 exchange standard. The identifier of the payment container is for example transmitted using this standard. Once this identifier has been obtained, the payment terminal implements a payment transaction in relation to the processing server to which it is connected. The data transmitted to the processing server are substantially identical to the data transmitted for payment by credit card excluding the PAN of the credit card, which is replaced by the identifier of the payment container. Furthermore, the merchant terminal may also include, in the transmitted data, a data representative of its merchant category code (MCC). If this data is not included in the data transmitted by the payment terminal, it is searched by the processing server.
    On the side of the banking server, the processing method is as follows: reception (TOI) of the data coming from the payment terminal, including the identifier of the payment container; obtaining (T02) a merchant identifier, possibly accompanied by a merchant category code when it is not provided by the merchant; according to the identifier of the payment container, determining (T03) an identifier of a banking establishment to which the payment container is attached; according to the bank identifier of the payment container, obtaining (T04) a payment authorization; and when the payment authorization issued, a transmission step (T05), to the merchant terminal, a data representative of the acceptance of the transaction; when the payment authorization is negative, a transmission step (T06) at the merchant terminal of a data representative of a refusal of the transaction.
    Thus, from the point of view of the merchant, the transaction takes place in the same way as a transaction carried out by credit card. As explained above, the payment authorization is obtained according to the identifier of the banking establishment: when the banking establishment of the payment container is the same as the banking establishment of the processing server (T041): obtaining ( T0411) attributes of the container; checking (T0412) the remaining balance within the payment container; when the remaining balance within the payment container is greater than the transaction amount (T0413): verification (T0414) that none of the attributes of the payment container are in contradiction with the transaction data (maximum amount, category authorized trader, etc.); when none (T0415) of the payment attributes are violated, issue of the payment authorization; subtracting (T0416) a transaction amount from the remaining balance within the payment container; when the remaining balance within the payment container is less than the transaction amount (T0417), transmission of a no authorization; when the banking establishment of the payment container is different from the banking establishment of the processing server (T042): identification (T0421) of the processing server to which the transaction data is to be transmitted; transmitting (T0422) transaction data to that processing server; receipt (T0423) of authorization or refusal of payment.
    The steps implemented by the processing server receiving transaction data are substantially identical to those described above. 5.5. Other ways of using a payment container.
    The following are other modes of use of a payment container in accordance with the present technique. These other modes of use tend to suppress the use of a communication terminal for use.
    According to a first variant, the use of the payment container by the user is carried out via a biometric authentication at the merchant. At first the user creates a payment container, this payment container can be limited geographically, temporally or by its amount (as explained above). Then the user goes to a merchant. At the time of payment, the user indicates that he wishes to make a payment by payment container and that he wishes to authenticate by biometrics. The user submits to a biometric identification (typically, a fingerprint reading), which triggers the payment. The system faces a technical difficulty: when the number of users increases, the identification of the holder at the merchant becomes tedious (because processing times are longer) and also source of errors. Indeed, the entity that performs the biometric comparison (a server for example) must compare the impression collected at the store to all those in the database. Thus, on the server side, it is proposed to accelerate this comparison by several techniques: (a) by dialing the user a PIN code of 4 digits: then divide by 10000 the comparison effort; (b) by sending the merchant to the payment terminal an information "The customer is a man" or "The customer is a woman": the comparison effort is then divided by two; (c) Assuming that the user has his mobile communication terminal on him, the comparison can be limited to the fingerprints of the mobile phone holders located near the merchant's payment terminal; (d) by requiring the user to enter the initials (first letter of the name, first letter of the first name), in order to limit comparison efforts in the database; This information makes it possible to divide the effort of comparison by 262 = 676 if one supposes that the distribution of the first letters of the surnames and given names is uniform. In practice, this is not necessarily the case, but the reduction is still important.
    Such a use supposes a possible modification of the process of creation of the payment container, so that it includes a new attribute, related to the fingerprint of the creator. The fingerprint, as such, can either already be available on the communication terminal or be prerecorded at the processing server.
    According to a second variant, the payment container, created using a communication terminal, can be used by two different people: in this case, either the creator and another person of his choice either they are two different people from the creator. Therefore, the recipient attribute can include an identification of several people. The use of the container is then made exclusively on the account of the creator (no transmission possible). In the case of biometric double authentication (as proposed in the previous variant), two representative fingerprint data are used in place of one.
    Of course, the number of users is not limited to two.
    Such use implies a possible modification of the process of creation of the payment container, so that it includes a new attribute, linked to the fingerprints of the creator and the authorized person. The fingerprint, as such, can either already be available on the communication terminal or be prerecorded at the processing server.
    According to a third variant, the payment container may be recurrent. This means that the payment container includes a periodicity attribute, allowing the processing server to create a new payment container, autonomously, by making a copy of a current payment container. This use is for example interesting during the regular use of a good or service, without the need to use his credit card to do so. Take, for example, the case of an employee who has lunch every lunchtime at work. The processing server created, every day, from Monday to Friday, so that the user can make his purchase without using his credit card.
    According to a fourth variant, the use of the payment container is monitored by the processing server so that it can implement anti-fraud measures. When a payment container, for example periodic, is used in a different way (for example in terms of location or range of amount) habits of the creator, confirmation of payment may be required from the user or a blockage of the container can be implemented by the processing server. 5.6. Implementing devices.
    In connection with FIG. 4, a device for creating and using a payment container, comprising means for executing the previously described methods, is described.
    For example, the processing device comprises a memory 41 constituted by a buffer memory, a processing unit 42, equipped for example with a microprocessor, and driven by the computer program 43, implementing the steps necessary for creation of a payment container on the one hand and their use on the other hand. At initialization, the code instructions of the computer program 43 are for example loaded into a memory before being executed by the processor of the processing unit 42. The processing unit 42 receives as input for example a set of initial lexemes or existing dictionary data. The microprocessor of the processing unit 42 implements the steps of the method, according to the instructions of the computer program 43 to allow access to the good or the service.
    For this, the processing device comprises, in addition to the buffer memory 41, means for obtaining information external to the device, such as a set of data accessible in base; these means may be in the form of an access module to a communication network such as a network card. The device also comprises processing means, these data for delivering data for selecting or entering payment container attributes; these processing means comprise for example a processor specialized in this task; the device also comprises one or more means for accessing one or more databases, such as contact databases and / or bank account databases and / or bank card databases. The device also comprises a non-contact reading module and / or a shooting module such as a camera.
    These means can be controlled by the processor of the processing unit 42 according to the computer program 43.
    In connection with FIG. 5, a payment container processing device is described comprising means for executing the previously described methods relating to the creation of a payment container or the processing of the payment container use by an user.
    For example, the verification device comprises a memory 51 constituted by a buffer memory, a processing unit 52, equipped for example with a microprocessor, and driven by the computer program 53, implementing necessary for the implementation performs verification functions. At initialization, the code instructions of the computer program 53 are for example loaded into a memory before being executed by the processor of the processing unit 52. The processing unit 52 receives as input, for example, a request to create or use a payment container. The microprocessor of the processing unit 52 implements the steps of the creation method, according to the instructions of the computer program 53 to allow the creation or use of such a container
    For this, the device comprises, in addition to the buffer memory 51, adapted processing means; these means can be in the form of a processor or a set of secure resources to secure the creation and processing of payment container. The device also comprises cryptographic processing means; these processing means comprise for example a dedicated encryption processor and encryption keys, such as session keys derived from an initial key.
    These means can be controlled by the processor of the processing unit 52 according to the computer program 53.
    权利要求:
    Claims (15)
    [1" id="c-fr-0001]
    1. A method for creating a payment data structure, called a payment container, a creation method implemented by a mobile communication terminal, said payment container comprising at least one datum representative of a bank identifier of a user, said method comprising: selecting (C20), by a user and via a human-machine interface, at least one attribute of said container; obtaining (C30), by the communication terminal, at least one datum representative of the user's bank card; validation (C40) by the user of the creation of the payment container; transmitting (C50), by said communication terminal, said payment container to a payment container processing server.
    [2" id="c-fr-0002]
    2. Method according to claim 1, characterized in that said obtaining step (C30) by the payment terminal, minus a datum representative of the user's bank card comprises: a step of transmission, to said bank card, via a contactless data transmission interface, a request for obtaining data, in the form of a signal; a step of receiving a response to said request, in the form of a modulated signal; a step of decoding said modulated signal delivering said at least one datum.
    [3" id="c-fr-0003]
    3. Method according to claim 1, characterized in that said obtaining step (C30) by the payment terminal, minus a datum representative of the user's bank card comprises: a step of activating a payment device; shooting of the communication terminal; a step of obtaining, with the aid of the shooting device, an image of the bank card; a step of implementing a character recognition module, from the image of the bank card, delivering said at least one data.
    [4" id="c-fr-0004]
    4. Creation method according to claim 1, characterized in that it further comprises a step of determining, by said communication terminal, a value representative of a transmission attribute of said payment container.
    [5" id="c-fr-0005]
    5. Creation method according to claim 4, characterized in that when the value representative of the transmission attribute of said payment container is positive, the method further comprises a step of determining, by said communication terminal, a representative value of a debit attribute of said payment container.
    [6" id="c-fr-0006]
    6. Creation method according to claim 1, characterized in that it comprises, prior to the selection of a container parameter, the activation (CIO), on the communication terminal of the user of a module of payment container management; the selection (C10-1), within this module, of a so-called container creation mode of operation.
    [7" id="c-fr-0007]
    7. Creation method according to claim 6, characterized in that the activation of the management module is accompanied by the authentication of said user to which said communication terminal and said payment card belong.
    [8" id="c-fr-0008]
    8. Method according to claim 1, characterized in that the selection, by a user and via a human-machine interface, of at least one attribute of said container comprises the selection of at least one value of attribute for at least one of the following parameters: date of validity of the payment container; period of validity of the payment container; amount of the payment container; category of beneficiary of the payment container; beneficiary of the payment container.
    [9" id="c-fr-0009]
    9. Device for creating a payment data structure, said payment container, said payment container comprising at least one datum representative of a user's banking identifier, said device comprising at least one module configured to enable : selecting (C20), by a user and via a human-machine interface, at least one attribute of said container; obtaining (C30), by the communication terminal, at least one datum representative of the user's bank card; the validation (C40) by the user of the creation of the payment container; transmitting (C50), by said communication terminal, said payment container to a payment container processing server.
    [10" id="c-fr-0010]
    10. Method of processing, by a processing server, a payment data structure, called a payment container, previously created according to a creation method according to one of claims 1 to 8, said payment container making the object of use with a merchant by a user having a communication terminal linked to said payment container, characterized in that it comprises the following steps: receipt (TOI) of data from the payment terminal , including the identifier of the payment container; obtaining (T02) a merchant identifier, possibly accompanied by a merchant category code when it is not provided by the merchant; according to the identifier of the payment container, determining (T03) an identifier of a banking establishment to which the payment container is attached; according to the bank identifier of the payment container, obtaining (T04) a payment authorization; and when the payment authorization issued, a transmission step (T05), to the merchant terminal, a data representative of the acceptance of the transaction;
    [11" id="c-fr-0011]
    11. Processing method according to claim 10, characterized in that said step of obtaining (T04) a payment authorization comprises the following steps: when the banking establishment of the payment container is the same as the banking establishment the processing server (T041): obtaining (T0411) attributes of the container; checking (T0412) the remaining balance within the payment container; when the remaining balance within the payment container is greater than the transaction amount (T0413): verification (T0414) that none of the attributes of the payment container are in contradiction with the transaction data (maximum amount, category authorized trader, etc.); when none (T0415) of the payment attributes are violated, issue of the payment authorization; subtracting (T0416) a transaction amount from the remaining balance within the payment container; when the remaining balance within the payment container is less than the transaction amount (T0417), transmission of a no authorization;
    [12" id="c-fr-0012]
    12. Processing method according to claim 11, characterized in that said step of obtaining (T04) a payment authorization comprises the following steps: when the banking establishment of the payment container is different from the banking establishment of the processing server (T042): identification (T0421) of the processing server to which the transaction data is to be transmitted; transmitting (T0422) transaction data to that processing server; receipt (T0423) of authorization or refusal of payment.
    [13" id="c-fr-0013]
    13. Processing server of a payment data structure, said payment container, previously created according to a device according to claim 9, said payment container being used by a merchant by a user having a communication terminal linked to said payment container, characterized in that it comprises: receiving (TOI) data from the payment terminal, including the identifier of the payment container; obtaining (T02) a merchant identifier, possibly accompanied by a merchant category code when it is not provided by the merchant; according to the identifier of the payment container, determining (T03) an identifier of a banking establishment to which the payment container is attached; according to the bank identifier of the payment container, obtaining (T04) a payment authorization; and when the payment authorization issued, a transmission step (T05) to the merchant terminal, a data representative of the acceptance of the transaction;
    [14" id="c-fr-0014]
    14. Computer program product downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor, characterized in that it comprises program code instructions for the execution of a creation method according to claim 1 when executed on a processor.
    [15" id="c-fr-0015]
    15. Computer program product downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor, characterized in that it comprises program code instructions for the execution of a processing method according to claim 10, of a payment container according to claim 14 when executed on a processor.
    类似技术:
    公开号 | 公开日 | 专利标题
    EP3113099B1|2021-01-13|Payment container, creation method, processing method, devices and programs therefor
    EP3243177B1|2021-11-17|Method for processing an authorisation to implement a service, devices and corresponding computer program
    EP2950256A1|2015-12-02|Identification method, device and corresponding program
    EP3163487B1|2021-08-18|Method, terminal, and computer program for securing the processing of transactional data
    EP3168769B1|2021-01-06|Method for assisting with the authentication of a user, corresponding server and computer program
    FR3054055B1|2019-09-06|METHOD FOR PROCESSING AT LEAST ONE PAYMENT MEASUREMENT DATA, PAYMENT TERMINAL AND CORRESPONDING COMPUTER PROGRAM
    EP2824625B1|2021-02-17|Method for conducting a transaction, corresponding terminal and computer program
    WO2008104704A1|2008-09-04|Electronic payment system including a mobile terminal comprising an electronic purse and a server
    EP2897095A1|2015-07-22|Method for securing a transaction conducted by bank card
    FR3052895A1|2017-12-22|METHOD FOR SENDING SECURITY INFORMATION
    FR3023640A1|2016-01-15|METHOD FOR MANAGING TRANSACTION, SERVER, COMPUTER PROGRAM PRODUCT AND CORRESPONDING STORAGE MEDIUM
    FR3090959A1|2020-06-26|Processing an electronic ticket service
    FR3083356A1|2020-01-03|METHOD OF PERFORMING A TRANSACTION, TERMINAL, SERVER AND CORRESPONDING COMPUTER PROGRAM
    FR3020166A1|2015-10-23|METHODS OF PROCESSING TRANSACTIONAL DATA, DEVICES AND PROGRAMS THEREOF
    FR3081246A1|2019-11-22|METHOD FOR MAKING A TRANSACTION, TERMINAL, SERVER AND CORRESPONDING COMPUTER PROGRAM
    FR3031608A1|2016-07-15|METHOD FOR PROCESSING AUTHORIZATION TO IMPLEMENT A SERVICE, DEVICES AND CORRESPONDING COMPUTER PROGRAM
    WO2017077210A1|2017-05-11|Method for verifying identity during virtualization
    FR3038766A1|2017-01-13|PAYMENT WITH SECURE QR CODE
    FR3045878A1|2017-06-23|AUTHENTICATION SERVER FOR CONTROLLING ACCESS TO A SERVICE
    FR3031609A1|2016-07-15|METHOD OF PROCESSING A TRANSACTION FROM A COMMUNICATION TERMINAL
    FR3008516A1|2015-01-16|TRANSACTION METHOD, TERMINAL AND CORRESPONDING COMPUTER PROGRAM.
    FR2963975A1|2012-02-24|ONLINE PAYMENT SYSTEM
    同族专利:
    公开号 | 公开日
    EP3113099B1|2021-01-13|
    US20170004502A1|2017-01-05|
    CA2934716A1|2017-01-03|
    US10997602B2|2021-05-04|
    ES2856696T3|2021-09-28|
    FR3038429B1|2018-09-21|
    EP3113099A1|2017-01-04|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US20120150687A1|2010-12-13|2012-06-14|Hart Annmarie D|Systems and methods for conducting contactless payments using a mobile device and a magstripe payment card|
    KR20120105296A|2011-03-15|2012-09-25|한국정보통신주식회사|Method and system for processing one time card payment and server, smart phone thereof|
    US20040019571A1|2002-07-26|2004-01-29|Intel Corporation|Mobile communication device with electronic token repository and method|
    JP2007531100A|2004-03-22|2007-11-01|コーニンクレッカフィリップスエレクトロニクスエヌヴィ|Electronic payment for content|
    US8453226B2|2010-07-16|2013-05-28|Visa International Service Association|Token validation for advanced authorization|
    EP2649745A4|2010-12-10|2014-05-07|Electronic Payment Exchange|Tokenized contactless payments for mobile devices|
    US10482457B2|2011-10-17|2019-11-19|Capital One Services, Llc|System and method for token-based payments|
    CN105264558A|2013-04-04|2016-01-20|维萨国际服务协会|Method and system for conducting pre-authorized financial transactions|
    US20150254647A1|2014-03-04|2015-09-10|Bank Of America Corporation|Flexible funding account token associations|KR102088451B1|2012-02-29|2020-03-12|모비웨이브 인코포레이티드|Method, device and secure element for conducting a secured financial transaction on a device|
    US10546444B2|2018-06-21|2020-01-28|Capital One Services, Llc|Systems and methods for secure read-only authentication|
    US10769299B2|2018-07-12|2020-09-08|Capital One Services, Llc|System and method for dynamic generation of URL by smart card|
    US10771253B2|2018-10-02|2020-09-08|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    CA3114753A1|2018-10-02|2020-04-09|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    WO2020072474A1|2018-10-02|2020-04-09|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    BR112021005150A2|2018-10-02|2021-06-15|Capital One Services, Llc|data transmission system, method of guiding a transmission device, and receiving application|
    US10771254B2|2018-10-02|2020-09-08|Capital One Services, Llc|Systems and methods for email-based card activation|
    US10992477B2|2018-10-02|2021-04-27|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    WO2020072413A1|2018-10-02|2020-04-09|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    US10607214B1|2018-10-02|2020-03-31|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    US10581611B1|2018-10-02|2020-03-03|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    US10542036B1|2018-10-02|2020-01-21|Capital One Services, Llc|Systems and methods for signaling an attack on contactless cards|
    US10565587B1|2018-10-02|2020-02-18|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    US10783519B2|2018-10-02|2020-09-22|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    US10511443B1|2018-10-02|2019-12-17|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    KR20210066798A|2018-10-02|2021-06-07|캐피탈 원 서비시즈, 엘엘씨|System and method for cryptographic authentication of contactless card|
    SG11202102543WA|2018-10-02|2021-04-29|Capital One Services Llc|Systems and methods for cryptographic authentication of contactless cards|
    US10554411B1|2018-10-02|2020-02-04|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    US10949520B2|2018-10-02|2021-03-16|Capital One Services, Llc|Systems and methods for cross coupling risk analytics and one-time-passcodes|
    US10909527B2|2018-10-02|2021-02-02|Capital One Services, Llc|Systems and methods for performing a reissue of a contactless card|
    CA3115252A1|2018-10-02|2020-04-09|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    US11210664B2|2018-10-02|2021-12-28|Capital One Services, Llc|Systems and methods for amplifying the strength of cryptographic algorithms|
    US10582386B1|2018-10-02|2020-03-03|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    US10579998B1|2018-10-02|2020-03-03|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    US10685350B2|2018-10-02|2020-06-16|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    US10489781B1|2018-10-02|2019-11-26|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    SG11202101171VA|2018-10-02|2021-03-30|Capital One Services Llc|Systems and methods for cryptographic authentication of contactless cards|
    US10733645B2|2018-10-02|2020-08-04|Capital One Services, Llc|Systems and methods for establishing identity for order pick up|
    US10748138B2|2018-10-02|2020-08-18|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    US10505738B1|2018-10-02|2019-12-10|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    US10592710B1|2018-10-02|2020-03-17|Capital One Services, Llc|Systems and methods for cryptographic authentication of contactless cards|
    US10680824B2|2018-10-02|2020-06-09|Capital One Services, Llc|Systems and methods for inventory management using cryptographic authentication of contactless cards|
    US11037136B2|2019-01-24|2021-06-15|Capital One Services, Llc|Tap to autofill card data|
    US11120453B2|2019-02-01|2021-09-14|Capital One Services, Llc|Tap card to securely generate card data to copy to clipboard|
    US10467622B1|2019-02-01|2019-11-05|Capital One Services, Llc|Using on-demand applications to generate virtual numbers for a contactless card to securely autofill forms|
    US10510074B1|2019-02-01|2019-12-17|Capital One Services, Llc|One-tap payment using a contactless card|
    US10425129B1|2019-02-27|2019-09-24|Capital One Services, Llc|Techniques to reduce power consumption in near field communication systems|
    US11082229B2|2019-03-18|2021-08-03|Capital One Services, Llc|System and method for pre-authentication of customer support calls|
    US10438437B1|2019-03-20|2019-10-08|Capital One Services, Llc|Tap to copy data to clipboard via NFC|
    US10984416B2|2019-03-20|2021-04-20|Capital One Services, Llc|NFC mobile currency transfer|
    US10643420B1|2019-03-20|2020-05-05|Capital One Services, Llc|Contextual tapping engine|
    US10535062B1|2019-03-20|2020-01-14|Capital One Services, Llc|Using a contactless card to securely share personal data stored in a blockchain|
    US10970712B2|2019-03-21|2021-04-06|Capital One Services, Llc|Delegated administration of permissions using a contactless card|
    US10516447B1|2019-06-17|2019-12-24|Capital One Services, Llc|Dynamic power levels in NFC card communications|
    US10871958B1|2019-07-03|2020-12-22|Capital One Services, Llc|Techniques to perform applet programming|
    US10713649B1|2019-07-09|2020-07-14|Capital One Services, Llc|System and method enabling mobile near-field communication to update display on a payment card|
    US10885514B1|2019-07-15|2021-01-05|Capital One Services, Llc|System and method for using image data to trigger contactless card transactions|
    US10733601B1|2019-07-17|2020-08-04|Capital One Services, Llc|Body area network facilitated authentication or payment authorization|
    US11182771B2|2019-07-17|2021-11-23|Capital One Services, Llc|System for value loading onto in-vehicle device|
    US10832271B1|2019-07-17|2020-11-10|Capital One Services, Llc|Verified reviews using a contactless card|
    US10506426B1|2019-07-19|2019-12-10|Capital One Services, Llc|Techniques for call authentication|
    US10541995B1|2019-07-23|2020-01-21|Capital One Services, Llc|First factor contactless card authentication system and method|
    US10701560B1|2019-10-02|2020-06-30|Capital One Services, Llc|Client device authentication using contactless legacy magnetic stripe data|
    US10862540B1|2019-12-23|2020-12-08|Capital One Services, Llc|Method for mapping NFC field strength and location on mobile devices|
    US10657754B1|2019-12-23|2020-05-19|Capital One Services, Llc|Contactless card and personal identification system|
    US11113685B2|2019-12-23|2021-09-07|Capital One Services, Llc|Card issuing with restricted virtual numbers|
    US10733283B1|2019-12-23|2020-08-04|Capital One Services, Llc|Secure password generation and management using NFC and contactless smart cards|
    US10885410B1|2019-12-23|2021-01-05|Capital One Services, Llc|Generating barcodes utilizing cryptographic techniques|
    US10853795B1|2019-12-24|2020-12-01|Capital One Services, Llc|Secure authentication based on identity data stored in a contactless card|
    US10664941B1|2019-12-24|2020-05-26|Capital One Services, Llc|Steganographic image encoding of biometric template information on a card|
    US11200563B2|2019-12-24|2021-12-14|Capital One Services, Llc|Account registration using a contactless card|
    US10757574B1|2019-12-26|2020-08-25|Capital One Services, Llc|Multi-factor authentication providing a credential via a contactless card for secure messaging|
    US10909544B1|2019-12-26|2021-02-02|Capital One Services, Llc|Accessing and utilizing multiple loyalty point accounts|
    US11038688B1|2019-12-30|2021-06-15|Capital One Services, Llc|Techniques to control applets for contactless cards|
    US10860914B1|2019-12-31|2020-12-08|Capital One Services, Llc|Contactless card and method of assembly|
    US11210656B2|2020-04-13|2021-12-28|Capital One Services, Llc|Determining specific terms for contactless card activation|
    US11030339B1|2020-04-30|2021-06-08|Capital One Services, Llc|Systems and methods for data access control of personal user data using a short-range transceiver|
    US10915888B1|2020-04-30|2021-02-09|Capital One Services, Llc|Contactless card with multiple rotating security keys|
    US11222342B2|2020-04-30|2022-01-11|Capital One Services, Llc|Accurate images in graphical user interfaces to enable data transfer|
    US10861006B1|2020-04-30|2020-12-08|Capital One Services, Llc|Systems and methods for data access control using a short-range transceiver|
    US10963865B1|2020-05-12|2021-03-30|Capital One Services, Llc|Augmented reality card activation experience|
    US11100511B1|2020-05-18|2021-08-24|Capital One Services, Llc|Application-based point of sale system in mobile operating systems|
    US11063979B1|2020-05-18|2021-07-13|Capital One Services, Llc|Enabling communications between applications in a mobile operating system|
    US11216623B1|2020-08-05|2022-01-04|Capital One Services, Llc|Systems and methods for controlling secured data transfer via URLs|
    US11062098B1|2020-08-11|2021-07-13|Capital One Services, Llc|Augmented reality information display and interaction via NFC based authentication|
    US11165586B1|2020-10-30|2021-11-02|Capital One Services, Llc|Call center web-based authentication using a contactless card|
    US11216799B1|2021-01-04|2022-01-04|Capital One Services, Llc|Secure generation of one-time passcodes using a contactless card|
    US11245438B1|2021-03-26|2022-02-08|Capital One Services, Llc|Network-enabled smart apparatus and systems and methods for activating and provisioning same|
    法律状态:
    2016-07-29| PLFP| Fee payment|Year of fee payment: 2 |
    2017-01-06| PLSC| Publication of the preliminary search report|Effective date: 20170106 |
    2017-07-26| PLFP| Fee payment|Year of fee payment: 3 |
    2018-07-26| PLFP| Fee payment|Year of fee payment: 4 |
    2019-07-25| PLFP| Fee payment|Year of fee payment: 5 |
    2020-07-23| PLFP| Fee payment|Year of fee payment: 6 |
    2021-07-28| PLFP| Fee payment|Year of fee payment: 7 |
    2022-01-07| TP| Transmission of property|Owner name: BANKS AND ACQUIRERS INTERNATIONAL HOLDING, FR Effective date: 20211202 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1556349A|FR3038429B1|2015-07-03|2015-07-03|PAYMENT CONTAINER, CREATION METHOD, PROCESSING METHOD, DEVICES AND PROGRAMS THEREOF|FR1556349A| FR3038429B1|2015-07-03|2015-07-03|PAYMENT CONTAINER, CREATION METHOD, PROCESSING METHOD, DEVICES AND PROGRAMS THEREOF|
    EP16177234.8A| EP3113099B1|2015-07-03|2016-06-30|Payment container, creation method, processing method, devices and programs therefor|
    ES16177234T| ES2856696T3|2015-07-03|2016-06-30|Payment container, creation procedure, treatment procedure, devices and corresponding programs|
    US15/201,547| US10997602B2|2015-07-03|2016-07-04|Payment container, method for creating, method for processing, corresponding devices and programs|
    CA2934716A| CA2934716A1|2015-07-03|2016-07-04|Payment container, method for creating, method for processing, corresponding devices and programs|
    [返回顶部]